 |
Wichtig !!! | |
N E U E S ... | |
Inhalt | |
Hotline | |
Stichwortverzeichnis |
Omikron Basic 6 Native für PowerMac
Version 6.13 vom 16.2.1998
Handbuch
|
Wichtig !!! | |
N E U E S ... | |
Inhalt | |
Hotline | |
Stichwortverzeichnis |
Speicherorganisation
Application Heap
Block Storage Section (BSS)
Data-Section
Der Application-Heap ist ein Speicherbereich, der Ihrem Programm vom Betriebssystem zugeteilt wird. Wenn Sie zum Beispiel mit dem MEMORY-Befehl einen Speicherblock anfordern, so wird er aus dem Application-Heap genommen.
Weiterhin gibt es eine ganze Reihe von Betriebssystemfunktionen, die Speicherblöcke im Application-Heap allozieren. Auch wenn Sie selber keineMAC_OS-Befehle in Ihrem Programm verwenden, so kann es trotzdem zu solchen Speicheranforderungen kommen, da diverse Omikron Basic Befehle in MAC_OS-Aufrufe umgesetzt werden.
Auch der Pufferspeicher des Omikron Basic Ausgabefensters wird im Applicationheap angelegt. Der dafür notwendige Speicher berechnet sich dabei zu Breite * Höhe * Farbebenen/8+ 1024. Wenn Sie also das Ausgabefenster benutzen, sollten Sie den Applicationheap mindestens auf diese Größe einstellen und zusätzlich noch wenigstens 65K für das Betriebssystem reservieren.
Die Größe des Application-Heaps kann man mit den beiden Compiler-Steuerwörtern COMPILER "MIN_SIZE X" und COMPILER "PRE_SIZE X" schon zur Compilierungszeit festlegen. Dabei gibt X im ersten Fall an, wie groß der Speicher mindestens sein muß, damit Ihr Programm überhaupt läut und im zweiten Fall, wieviel Speicher Ihr Programm bevorzugt benötigen würde.
Falls genug freier Speicher vorhanden ist, bekommt Ihr Programm den bei PRE_SIZE angegebenen Wert, ansonsten weniger. Falls nicht mal die bei MIN_SIZE eingetragene Speichermenge frei ist, wird der Programmstart mit einer Fehlermeldung abgebrochen.
Hinweis: Beide Größen lassen sich auch nachträglich verändern, indem man das Programmicon selektiert und dann im Finder 'Information' anklickt.
Am oberen Ende der BSS befindet sich der vom Omikron Basic verwaltete Stack. Er dient hauptsächlich dazu, lokale Variablen zu speichern. Im allgemeinen reichen für den Stack 16K aus. Wenn Sie allerdings rekursive Prozedur- oder Funktionsaufrufe mit hoher Schachteltiefe machen, so sollten Sie für den Stack mehr Speicher reservieren, um das Risiko zu vermeiden, daß der Stack in den Garbage-Bereich wächst.
Auch der SORT-Befehl benötigt größere Mengen Speicher auf dem Stack. Wenn Sie diesen Befehl zum Umsortieren größerer Felder benötigen, sollten Sie auf jedenfall mehr Stackspeicher reservieren. Dazu dient das Compiler-Steuerwort COMPILER "STACK X", wobei X die gewünschte Stackgröße angibt.
Unterhalb des Stacks liegen die Bereiche Garbage, Stringheap und Arrays. Dabei werden die Grenzen zwischen diesen Bereichen vom Omikron Basic dynamisch verwalten. Wenn z. B. im Array-Bereich durch einen DIM-Befehl mehr Platz gebraucht wird, dann wird der Stringheap nach oben geschoben und damit der Garbagebereich verkleinert. Da zur Compilierungszeit ja noch nicht bekannt ist, wie groß Ihre Felder mal dimensioniert werden bzw. wieviele Strings Ihr Programm zur Laufzeit anlegt und wie lang die einzelnen Strings sein werden, kann der Compiler nicht ausrechnen, wieviel Platz er für diese drei Bereiche reservieren muß. Sie müssen darum mit dem Compiler-Steuerwort COMPILER "BAS_MEM X" einen Wert vorgeben.
Um abzuschätzen, welcher Wert für X einzusetzen ist, nachfolgend einige Hinweise:
1. Der Platzbedarf von numerischen Arrays berechnet sich aus der Anzahl der enthaltenen Elemente mal der Bytezahl, die der verwendete Datentyp benötigt (Bit 1/8 Byte, Byte 1 Byte, Integer 2 Byte, Longinteger 4 Byte, single Float 4 Byte und double Float 8 Byte). Dazu kommen noch mindestens 16 Byte Verwaltungsinformation für das Feld.
2. Für Stringfelder sind 8 Byte pro Feldelement anzusetzen. Dazu kommt dann noch die Länge des eigentlichen Strings auf eine durch 8 teilbare Zahl aufgerundet und mit 2 multipliziert und weitere 8 Byte Verwaltung pro String. Wenn genug Speicher frei ist, kann man das Ergebnis auch noch gerne mit 2 oder 3 multiplizieren.
3. Der Garbagebereich wird benutzt, um vorübergehend Strings anzulegen. Z.B. wird bei einer Stringaddition das Ergebnis zunächst im Garbagebereich zusammengebaut und dann erst einer Stringvariablen zugewiesen. Auch Matrizenoperationen benötigen Platz im Garbagebereich. Dabei muß ein Feld der verwendeten Größe einmal in den Garbagebereich passen.
Unterhalb der Arrays befindet sich noch ein weiterer Block, der intern vom Omikron Basic verwaltet wird.
Die Data-Section enhält z.B. die TOC (Table of Contents) und die im Programm verwendeten Konstanten. Die Data-Section wird intern vom Omikron Basic verwaltet und hat nichts mit dem Befehl DATA zu tun.
Der VT52 Emulator 
blättern 
Tabelle der MIDI-Noten